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A METHOD AND AN APPARATUS FOR IMPLEMENTING A KEY FRAME 

BACKGROUND 

This application claims the benefit of the earlier filing date of co- 
pending provisional applications of Hawley K. Rising, III and Ali J. Tabatabai 
entitled, "A Proved Structure for the Key Frame DS," Serial No. 60/168,433, 
filed November 30\l999 and "A Method and an Apparatus for Implementing 
A Key Frame/' Serial Vo. , filed October 20, 2000. 

FIELD OF THE INVENTION 

This invention relates generally to describing and accessing of data. 
More specifically, the invention relates to mechanisms and techniques that 
enable data related to an audiovisual work to be described and accessed. 



BACKGROUND 

Key frames have a variety of uses in terms of describing data pertaining 
to an audiovisual work. A key frame is a single frame that tags a plurality of 
frames related to a sequence of images that meet certain criteria designated by 
a user. For example, a description such as a title of a scene to a movie, or 
other information related to a particular scene may be recorded in a key 
frame. In this manner, the key frame is able to provide a summary of an 
audiovisual work that allows near random access to frames within the 
audiovisual work. In addition to describing audiovisual data, key frames may 
also be used for comparing a video with another video or for reviewing a 
summary of the series of frames in a document that is generated from the key 
frame. 

One disadvantage to a key frame is that it is generally static. Once a key 
frame is made, the key frame generally cannot be updated. If the criteria for 
the key frame is changed, a new key frame must be created. Creating a new 
key frame is time consuming and expensive. It is therefore desirable to have 
a system that addresses this disadvantage. 
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SUMMARY 

One embodiment relates to a key frame such as a key frame description 
scheme (KeyFrameDS) that may be used to describe or summarize a work 
such as an audiovisual work based upon a criterion or criteria provided by, for 
5 example, a user. KeyFrameDS, that includes a set of attributes such as other 

description schemes, describes changes that are to be made to the set of 
description schemes. KeyFrameDS may use attribute groups containing sets 
of attributes such as the key, length, and value (KLV) to accomplish this task. 
The KeyFrameDS may be updated in a variety of ways. In one 
10 embodiment, KeyFrameDS is updated by modifying an attribute such as the 

value attribute. In another embodiment, KeyFrameDS is updated by adding, 
deleting, or changing description schemes attached to the value attribute of a 
■Jg KLV attribute group. These methods for updating the KeyFrameDS allow a 

r rj user to select, for example, another set of frames in an audiovisual work to 

NI.5 provide another description or summary to the audiovisual work. Updating 

|I the KeyFrameDS may be accomplished by a sender (e.g., a server, a broadcast 

unit, etc.) sending a command such as a commandDS to a receiver (e.g., client, 
" set- top box, etc.). CommandDS includes instructions such as to add, change, 

fy or delete one or more attributes or to add, change or delete a description 

!3>0 scheme. 

O One example of updating a KeyFrameDS relates to a person, driving in 

a vehicle with a portable computer device, who is initially interested in 
touring historical sites in a city. A KeyFrameDS, that includes the attribute 
groups KjI^Vj, may be used to provide a summary of these historical sites. At 

25 about noon, the person may be interested in finding restaurants in the city. In 

order to view a list of restaurants, the person inputs information that changes 
the value attribute (Vj) in the K^Vj attribute group in the KeyFrameDS that 
searches historical sites to restaurants. The length of bytes associated with the 
value attribute typically changes when the value attribute changes, so the 

30 attribute 1^ is modified to attribute L 2 . The remainder of the information in 

the KLV attribute group of the KeyFrameDS remains unchanged by the user 
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such as the city in which the search is to be performed. The computer system 
executes this request and presents a list of restaurants to the user. 

Another embodiment of KeyFrameDS involves placing entities such as 
other description schemes into the value attribute of a KLV attribute group in 
a KeyFrameDS in a universally recognizable format, such as in a description 
definition language (DDL). By using KeyFrameDS that have these 
characteristics, the value attribute of the KeyFrameDS may be modified 
regardless of syntactic or semantic distinctions that may exist between, for 
example, semantic data that describes a syntactic audiovisual object. Other 
features and advantages of the invention will be apparent from the 
accompanying drawings and from the detailed description that follows below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not 
limitation in the figures of the accompanying drawings, in which like 
references indicate similar elements, and in which: 

Figure 1 illustrates a block diagram of one embodiment of a computer 
system that includes servers; 

Figure 2 illustrates a block diagram of one embodiment of another 
computer system related to a peer-to-peer system; 

Figure 3 illustrates a block diagram of another embodiment of a 
computer system; and 

Figure 4 illustrates a flow diagram of one embodiment for updating a 
key frame. 

DETAILED DESCRIPTION 

When creating an audiovisual work, it is desirable to provide a 
description or a summary of portions of the audiovisual work that contain 
certain criteria designated by a person such as a user of a computer system. 
The criteria may be changed to incorporate different information. To 
accommodate the changed criterion or criteria, one embodiment allows a key 
frame such as a key frame description scheme (KeyFrameDS) to be used. 
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KeyFrameDS is a description scheme that includes other description schemes. 
To adjust for the changed criteria, the KeyFrameDS is updated. 

To understand the manner in which the KeyFrameDS may be 
modified, an explanation of the structure of the KeyFrameDS is provided. 
5 The KeyFrameDS includes a list of attribute groups. Each attribute group 

includes a key, length, and value attribute (KLV). The key attribute, typically 
an object/class, describes other description schemes. For instance, the key 
attribute may indicate that the key frame relates to the rules of a soccer game 
that is to be broadcast. The length attribute generally refers to the number of 
10 bytes associated with the value attribute. The value attribute, that includes 

one or more elements, is used to instantiate the object or class provided by the 
key attribute. The value attribute is where a set of description schemes attach 
• % q thereto. Typically, the value attribute and the length attribute are modified 

gfjl. whereas the key attribute generally remains unchanged when values are 

altered. If the description schemes themselves are altered, the key attribute 
M changes to reflect the new description scheme name. 

" Updating the KeyFrameDS includes adding, deleting, or modifying 

" attributes in attribute groups contained in KeyFrameDS. There are at least 

ry two general ways in which the KeyFrameDS is updated. First, the value 

;;S20 contained in a value attribute of a KLV attribute group of the KeyFrameDS 

C3 may be modified. Second, the value attribute may be modified by updating 

the description schemes contained in or pointed to by the value attribute. 
Updating the KeyFrameDS may be accomplished by a sender (e.g., a server, a 
broadcast unit, etc.) sending a command such as a commandDS to a receiver 
25 (e.g., client, set- top box, etc.). 

The commandDS contains information for making a change to at least 
one attribute of the KeyFrameDS or add, delete, or change a description 
scheme. The commandDS may require that the change occur at read time or 
any other suitable time. 
30 By implementing techniques of the invention, a user may update a 

KeyFrameDS during, for example, a broadcast of a sports program on a 
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television. Additionally, the state of the descriptions may change to reflect a 
change to the underlying audiovisual content. 

In the following description, numerous specific details such as specific 
materials, processing parameters, processing steps, etc., are set forth in order to 
5 provide a thorough understanding of the invention. One skilled in the art 

will recognize that these details need not be specifically adhered to in order to 
practice the claimed invention. In other instances, well known processing 
steps, materials, etc., are not set forth in order not to obscure the invention. 
Figures 1 through 3 illustrate computer systems that may implement 
10 various features of a KeyFrameDS to change attributes such as description 

schemes. To better understand techniques of the invention that are 
implemented using various computer systems, definitions of terms are 
provided. A description scheme is a characteristic associated with the data 
? gi and may be the value of a value attribute. Such attributes may include 

; 415 syntactic description schemes {e.g., arrangement of words), semantic 

il description schemes (e.g., meanings of words), a mixture of these description 

^ schemes, or any other suitable characteristics of data. The attributes of the 

!M KeyFrameDS may be dynamically changed by a user, a server, a client, or any 

ry other suitable device. 

J^20 The KeyFrameDS includes attributes such as key, length, and value 

Q (KLV), grouped into the KLV attribute groups. Key attribute is a tag that 

uniquely identifies an object/class (e.g., a set of data with similar 
characteristics). A key attribute describes a description scheme and typically 
remains unchanged. Length attribute is the number of bytes associated with 
25 the value attribute. The length attribute may be skipped if a receiver (e.g., 

client, set-top box, etc.) of the KeyFrameDS does not recognize the object/class 
thereby reducing the amount of time to process a KeyFrameDS. The value 
attribute, on the other hand, is used to instantiate the object/class. 

Given this description of KeyFrameDS and attributes, a block diagram 
30 of one embodiment of computer system 1 that implements principles of the 

invention is presented in Figure 1. 
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I. SERVER IMPLEMENTATION OF TECHNIQUES OF THE 
INVENTION 

KeyFrameDS interactions may be implemented on a server-side 
through servers (2, 4) and on the client-side through clients (6, 8). Each of 
these implementations is discussed below. 

A. SERVER-SIDE INTERACTION WITH A KEY FRAME 

Computer system 1 includes servers (2, 4) and clients (6, 8). Clients (6, 
8) are applications that operate on a personal computer or a workstation to 
input data used in key frames. Servers (2, 4) are computers or devices on a 
network that manage network resources. For example, server 2 is a computer 
and storage device dedicated to the task of storing data and searching 
KeyFrameDS. Program instructions (e.g., computer program, software, etc.) 
reside in server 2. Program instructions that may enhance techniques of the 
invention include a standard generalized markup language such as extensible 
markup language schemes (XML) and description definition language (DDL). 
Scheme XML uses two types of data items such as elements and attributes in 
order to change a description in, for example, a KeyFrameDS, related to an 
audiovisual work. 

Another embodiment of KeyFrameDS involves placing the key frame 
in a universally recognizable format, such as in the DDL. -By using 
KeyFrameDS that have these characteristics, an attribute group such as the 
value attribute group of the KeyFrameDS may be modified regardless of 
syntactic or semantic distinctions that may exist between, for example, 
semantic data that describes a syntactic audiovisual object. In comparison to 
the functions of server 2, server 4 may be a file server, print server, or any 
other suitable server to perform certain functions. 

On the server-side, a mechanism is used for updating KeyFrameDS. 
There are at least two general ways in which a KeyFrameDS is updated. In 
one embodiment, KeyFrameDS is updated by modifying an attribute such as 
the value attribute. In another embodiment, KeyFrameDS is updated by 
attaching, adding, deleting, or changing description schemes. 
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Updating the KeyFrameDS may be accomplished by a sender such as 
server 4 sending a commandDS to a receiver such as server 2. CommandDS 
contains the information to update the KeyFrameDS. For example, 
commandDS includes changes to at least one description scheme by indicating 
that a KLV attribute group, for instance, K 1 L 1 V 1/ should be changed to the 
KLV attribute group K l L 2 V 2 . CommandDS identifies that the key is K a which 
is the same as the key attribute in the original KLV attribute group in the 
original KeyFrameDS. This identifiers the particular key frame (e.g., 
KeyFrameDS) to be updated and, in particular, the attribute to be updated in 
the KeyFrameDS. L 2 is the length of the new value attribute V 2 . 

CommandDS allows a receiver to add, change, or delete parts of a 
description (e.g., an audio description scheme related to descriptions of sound) 
dynamically based upon the user preferences (e.g., recordation of a title of a 
movie, important scenes in a movie, etc.) and or domain-specific attributes. 
The commandDS may also contain information for making the change 
during read time or at any other suitable time. The code for commandDS is as 
follows: 

<datatype name= / commandTypes / > 
<basetype name= / string , /> 
<enumeration> 

<literal>add</literal> 
<literal>change< / literal> 
<literal>delete</literal> 
< / enumer ation> 
</datatype> 

<DSType name = 'CommandDS /> 

<attribute name = 'command 7 type ='commandTypes' 
minOccurs= , l / maxOccurs='l'/> 

<attrGroupRef name = 'KLV'/> 
</DSType> 

As noted in the commandDS code, the instructions include, for 
example, to add, change, or delete information associated with KeyFrameDS. 



080398.P330 

CommandDS, executed on server 2, may automatically update the 
KeyFrameDS and then search for data in a database such as that which is 
stored on server 2 that complies with the requirements established by the new 
KeyFrameDS. To illustrate, commandDS may require that an attribute for the 
KeyFrameDS be modified based upon a factor such as time (e.g., every fifteen 
seconds an attribute such as the value attribute automatically changes based 
upon program instructions executed on the server). 

The commandDS may require that an attribute or attributes (e.g., 
description schemes) attached to the KLV attribute group of a key frame such 
as KeyFrameDS change, for example, every fifteen seconds. To illustrate, a 
KeyFrameDS such as gameKeyFrameDS may be used in a sports program such 
as a soccer game. If a soccer game is being played, one screen of a split screen 
may be used to display information pertaining to the soccer players. 
GameKeyFrameDS may be used to automatically control the type of 
information displayed on, for example, a graphical user interface (GUI) of 
client 6. GameKeyFrameDS may include a plurality of attributes such as a 
player description scheme (playerDS), soccer description scheme (soccerDS), 
audio description scheme (audioDS), and transcoding description scheme 
(transcoding DS). Each description scheme may appear on a GUI as a 
hyperlink. In order to automatically change information related to a soccer 
player, an attribute such as the playerDS may be used that links the player's 
name to information such as the player's age, height, weight, and a short 
summary of the player's career history. Other information that may be related 
to playerDS includes a color descriptor to describe the color of the player's 
uniform. 

Server 2 could automatically change the attribute such as playerDS 
every fifteen seconds by changing the name of a first player to the name of a 
second player player. The player's name may be changed by, for instance, the 
program instructions alphabetically rotating players last name every fifteen 
seconds. Information such as age, height, weight, and career history that is 
associated with the name of the player is automatically updated when the 
player's name is changed. This new information is then sent over 
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interconnect 13 to client 6. A user may then view the new gameKeyFrameDS 
and the data associated with the gameKeyFrameDS. 

Other attributes that may be automatically modified by the program 
instructions include other descriptive schemes such as soccer description 
5 scheme (soccerDS), audio description scheme (audioDS), transcoding 

description scheme (transcodingDS), and time description scheme (timeDS). 
Each of these descriptive schemes is described below. 

SoccerDS contains descriptions related to the rules associated with the 
game of soccer. For example, this attribute may indicate that the soccer ball 
10 must be hit by a player into an area defined by goal posts and a net in order for 

a point to be added to the team's score. Another rule may be that a soccer 
q player cannot hold the soccer ball in his or her hands. Various other suitable 

rt rules may be incorporated into this attribute. 

fU AudioDS contains audio related descriptions for sound such as sound 

i yl5 effects, instruments, speech recognition, music, or any other suitable audio 

r] description. For example, audioDS may provide the voice of the sportscaster 

3 broadcasting the event. 

i*, TranscodingDS contains descriptions related to the coding type of the 

audiovisual work such as a picture. For example, transcoding may involve 
C320 converting from a picture format to another format (e.g., Moving Picture 

w Experts Group - 2 Standard (MPEG-2) to H. 263). 

TimeDS is generally composed of two elements: the start time point 
and the duration of a particular segment. Time stamping is used to mark 
areas in a multimedia work. To illustrate, a time stamp may be used to mark 
25 a certain play in the soccer game in order to allow that play to be replayed for 

the audience. Any one of these description schemes may be automatically 
modified by server 2 as explained herein. 

In addition to updating attributes (e.g., description schemes), another 
embodiment relates to weighting attributes of a KeyFrameDS. For example, 
30 one attribute may be assigned a weight of "1" that means very important such 

as playerDS and timeDS while the weight of "5" is assigned to another 
attribute and means least important such as soccerDS. 
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* 



In another example, an attribute such as a group name may be 
considered very important. Therefore, this attribute is assigned a value of 
importance of "1" such as for the key and length code provided below. 
<attrGroup name = 'REF_ID' 

<attribute name = 'id' type - 'ID' minOccurs='l' maxOccurs= , l , /> 

<attribute name = 'href type ='uri' minOccurs= , l / 
maxOccurs='l' / > 
</attrGroup> 
<attrGroup name = 'KLV 

<attribute name = 'key' type = 'ID' minOccurs='l' 
maxOccurs='l'/ > 

<attribute name = 'length' type='integer' minOccurs='l' 
maxOccurs='l ' / > 

<attribute name = 'value' type ='char' maxOccursPar= 'length '/> 
</attrGroup> 

<datatype name='attributeWeight'> 

<basetype name='integer'/> 

<minlnclusive> 1 </minInclusive> 

<maxlnclusive> 5 </maxInclusive> 
</datatype> 

<DSType name = 'KeyFrameDS'> 

<attrGroupRef name = 'REF_ID'/> 
<SubDSOf name = 'keyFrame'/> 
<attribute name = 'size' type = 'int'/> 
<seq minOccurs = '1' maxOccursPar = 'size'/> 
<attrGroupRef name = 'KLV'/> 

<attribute name = 'weight' type = 'attributeWeight' minOccurs = 
'0' maxOccurs = 'l'/> 

</seq> 
</DSType> 
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By allowing attributes to be weighted, server 2 or a user of a computer system 

is able to dynamically determine, for example, the types of attributes that 

should be more frequently displayed to a user. 

Additionally, KeyFrameDS may mark an audiovisual work through a 

5 reference identifier (ID) by using methods known in the art. A reference ID 

indicates a certain location in an audiovisual work. A reference ID may 

include a media or a medium locator to specify the "location" of a particular 

image, audio, or video segment by referencing the media data. There are 

generally four types of medium locators such as the video segment locator, 

10 the audio segment locator, the image locator, and the sound locator. In this 

manner, a user may randomly access frames designated with a reference ID. It 

will be appreciated that other methods may be used to mark a multimedia 

work such as an audiovisual work. 

^ B. CLIENT-SIDE INTERACTION WITH DYNAMIC KEY 

^jl5 FRAME 

ii Another implementation of updating the KeyFrameDS may be 

performed by a user inputting and sending changes using a commandDS 
I* through, for example, client 6 to a server of the computer system shown in 

jpy20 Figure 1. Clients (6, 8) rely upon a server such as servers (2, 4) to perform 

Jjf certain operations such as to input a commandDS to update KeyFrameDS in 

q order to access previously stored information related to the KeyFrameDS. 

Server 2 also allows or causes information to a KeyFrameDS to be added, 
changed, or deleted. 

25 The KeyFrameDS may be updated by having one of its attribute groups 

or weights changed such as the KLV (key, length, and value) attribute groups, 
or their corresponding weights. Generally, a user will modify a KLV attribute 
group by modifying the value attribute since the value attribute incorporates 
other attributes such as description schemes. For example, information such 

30 as the shot identification, the scene identification, and key-frame building, or 

selecting parameters may be modified by the user through client 6. If a 
shot/scene identification is to be changed, server 2 resegments the video, 
selects new key frames at the desired segment quantization level, and sends 
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these KeyFrameDS to client 6. The user may input attributes such as 
description schemes that are semantic, syntactic, or a mixture of those 
attributes into a client such as clients (6, 8). One means for inputting this 
information is by a user sending from client 6 a command such as 
commandDS to server 2. 

Server 2 receives and executes these instructions such as commandDS 
from client 6. Server 2 then may access information that has been stored in 
server 2 or server 4 such as data that is responsive to the KeyFrameDS. For 
instance, a very large collection of frames that may include a variety of 
possible parameter settings may be stored and accessed on server 2. Server 2 
selects segments from the stored KeyFrameDS that represent those segments 
and that fit the parameters inputted by a user. Server 2 then sends this new 
KeyFrameDS and data corresponding to the new KeyFrameDS to client 6. 

On the other hand, if the segments are to remain unchanged, the 
process reselects the KeyFrameDS for each segment and sends these 
KeyFrameDS' to client 6. If a query is processed, the KeyFrameDS are not in 
temporal order and the reordering of the KeyFrameDS is assumed. 

The KeyFrameDS structure, that uses DDL, provides greater flexibility 
by allowing attributes such as semantic, syntactic, a mixture of semantic and 
syntactic attributes, or any other suitable characteristics of data to be added, 
changed, or deleted by automatically modifying the attribute groups in the 
KeyFrameDS or by a user sending a commandDS that instructs that certain 
changes ,be made. It will be appreciated that the KeyFrameDS structure and 
the use of commandDS to change a content of the key frame structure may 
also be extended to define other description schemes with similar 
requirements. 

H. PEER-TO-PEER SYSTEM IMPLEMENTATION OF TECHNIQUES 
OF THE INVENTION 

It will be appreciated that a peer-to-peer system illustrated in Figure 2 
may be used in the KeyFrameDS interactions. Peer-to-peer system 3 is a type 
of network in which each workstation such as servers (14, 15) have equivalent 
capabilities and responsibilities. For example, there may be two peer 
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computers or servers on the same network. This differs from client/ server 

architectures, in which some computers are dedicated to serving the others. 

Peer-to-peer networks are generally simpler and less expensive, but they 

usually do not offer the same performance under heavy loads. 

In one embodiment, servers (14, 15) are coupled through interconnect 

13. Client 6 may access the KeyFrameDS to add, delete, or change a value for 

an attribute or an element for an attribute in KeyFrameDS. A commandDS 

may be sent to client 6 from server 14 to update KeyFrameDS. Once client 6 

has the initial list, updates such as in the form of adding, deleting, or 

modifying a KeyFrameDS may be sent from client 6 to server 14. Server 14 

then updates or changes the description scheme(s) as described above. Server 

15 may also perform in the same manner. 

m. COMPUTER SYSTEM IMPLEMENTATION OF TECHNIQUES 
OF THE INVENTION 

Figure 3 illustrates an embodiment of another computer system 100 
that implements the principles of the invention. Computer system 100 
includes a stand alone or portable computing device. Computer system 100 
comprises a processor 170, a storage device 180, and interconnect 150 such as a 
bus or a point-to-point link. Processor 170 is coupled to the storage device 180 
by interconnect 150. In addition, a number of user input/output devices, such 
as a keyboard 120 and display 125, are coupled to chip set (not shown) which is 
then connected to processor 170. The chipset (not shown) is typically 
connected to processor 170 using an interconnect that is different from 
interconnect 150. 

Processor 170 represents a central processing unit of any type of 
architecture (e.g., the Intel architecture, Hewlett Packard architecture, Sun 
Microsystems architecture, IBM architecture, etc.), or hybrid architecture. In 
addition, processor 170 could be implemented on one or more chips. Storage 
device 180 represents one or more mechanisms for storing data such as the 
plurality of elements that make up an attribute which may be incorporated 
into a key frame such as KeyFrameDS. Storage device 180 may include read 
only memory (ROM), random access memory (RAM), magnetic disk storage 
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media, optical storage media, flash memory devices, and /or other machine- 
readable media. Interconnect 150 represents one or more buses (e.g., 
accelerated graphics port bus, peripheral component interconnect bus, 
industry standard architecture bus, X-Bus, video electronics standards 
5 association related to buses, etc.) and bridges (also termed as bus controllers). 

While this embodiment is described in relation to a single processor 
computer system, the invention could be implemented in a multi-processor 
computer system. In addition to other devices, one or more of a network 130 
may be present. Network 130 represents one or more network connections 
10 for transmitting data over a machine readable media. The invention could 

also be implemented on multiple computers connected via such a network. 
Figure 3 also illustrates that the storage device 180 has stored therein 
3 data 135 and program instructions (e.g., software, computer program, etc.) 136. 

7g Data 135 represents data stored in one or more of the formats described 

^15 herein. Program instructions 136 represents the necessary code for 

d performing any and /or all of the techniques described with reference to 

jj Figures 1, 2, and 4. It will be recognized by one of ordinary skill in the art that 

the storage device 180 preferably contains additional software (not shown), 
<& which is not necessary to understanding the invention. 

L|20 Figure 3 additionally illustrates that the processor 170 includes decoder 

I 140. Decoder 140 is used for decoding instructions received by processor 170 

into control signals and /or microcode entry points. In response to these 
control signals and/or microcode entry points, decoder 140 performs the 
appropriate operations. 
25 Figure 4 illustrates a flow diagram of one embodiment for updating a 

key frame. At block 200, at least one attribute group, a set of attribute groups, 
or information pertaining to at least one description scheme is provided for 
an attribute such as KeyFrameDS. Attributes such as description schemes are 
attached to the value attribute to the KeyFrameDS. Attributes may be in the 
30 form of semantic, syntactic, or any other suitable characteristic of data. 

At block 210, attribute groups are inserted into a key frame such as the 
KeyFrameDS. At block 220, attributes such as other description schemes are 
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attached to an attribute group such as the value attribute . In one 
embodiment, a universally recognizable format such as DDL is used to insert 
the attributes into a KeyFrameDS. At block 230, the KeyFrameDS may be 
modified, for example, by a server, a user, a client, or other suitable device. A 
command such as a commandDS is sent to, for instance, a server that requires 
the server to process the KeyFrameDS to change information about the 
KeyFrameDS. At block 240, at least one attribute group of the KeyFrameDS 
may be updated. Typically, when updating a KLV attribute group, the value 
attribute or the length attribute are modified whereas the key attribute that 
describes the other description schemes generally remains unchanged, unless 
one is changing the description scheme to which the KLV attribute group 
refers. Alternatively, at least one attribute is added, deleted, or changed that is 
attached to the KeyFrameDS. At block 250, a key frame such as KeyFrameDS 
is processed. At block 260, the server or processor accesses stored information 
pertaining to the KeyFrameDS. This information may be stored in a storage 
medium or media such as a database or any other suitable means. In another 
embodiment, the server may connect to a network such as the Internet to 
access information. 

In the foregoing specification, the invention is described with reference 
to specific embodiments thereof. It will, however, be evident that various 
modifications and changes may be made thereto without departing from the 
broader spirit and scope of the invention as set forth in the appended claims. 
The specification and drawings are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 
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